Github-Pull: bitcoin#2249
Rebased-From: a6a4af1

…o the 'Available' label in the top bar

Github-Pull: bitcoin#2247
Rebased-From: e21a560

Set custom transaction fee to highest possible value in case input
is too big number.

Github-Pull: bitcoin#2237
Rebased-From: ae1837e

/rest/mempool/info.json

And use it to fix a race condition in mempool_persist.py:
https://travis-ci.org/Empact/bitcoin/jobs/487577243

Since e.g. getrawmempool returns errors based on this status, this
enables users to test it for readiness.
Github-Pull: bitcoin#2254
Rebased-From: 0169a75

So the loaded state is explicitly mempool-specific.

Github-Pull: bitcoin#2254
Rebased-From: f0de789

>>> backports bitcoin/bitcoin@fa3f9a0
Github-Pull: bitcoin#2254
Rebased-From: d076c81

>>> backports bitcoin/bitcoin@cc84460
Github-Pull: bitcoin#2254
Rebased-From: 2488ebc

Co-Authored-By: Wladimir J. van der Laan <laanwj@gmail.com>

Plus adapted it to PIVX.

Github-Pull: bitcoin#2262
Rebased-From: caa6734

…ain()`

Github-Pull: bitcoin#2284
Rebased-From: e560afd

Essentially, we were re-serializing every new connected block tip just to calculate the size and broadcast a notification for external listeners if the block size is above 1mb.

Which well..

(1) the block arrives serialized from the network and it's parsed into a block object by the core, there is no need to re-serialize the entire block..

(2) the complete serialization is just done to notify external listeners if a block exceeds the 1mb block size..  --> which can easily be done from outside of the core without having the most important node processing thread's work notifying nor calculating it, blocking cs_main for its whole time..

Github-Pull: bitcoin#2284
Rebased-From: 479d065

Ensures ordering of callbacks within a SingleThreadedSchedulerClient
with respect to each other

Github-Pull: bitcoin#2290
Rebased-From: 4ea2048

…he memory model

Github-Pull: bitcoin#2290
Rebased-From: cb9bb25

…ading and memory model

Github-Pull: bitcoin#2290
Rebased-From: f9d2ab3

Ensures that callbacks are invoked in the order in which the chain is updated
Resolves bitcoin#12978

Github-Pull: bitcoin#2290
Rebased-From: ef24337

If the ShutdownRequested() check at the top of ActivateBestChain()
returns false during initial genesis block load we will fail an
assertion in UTXO DB flush as the best block hash IsNull(). To work
around this, we move the check until after one round of
ActivateBestChainStep(), ensuring the genesis block gets connected.

Github-Pull: bitcoin#2290
Rebased-From: 8640be1

Github-Pull: bitcoin#2290
Rebased-From: 8d15cf5

Technically, some internal datastructures may be in an inconsistent
state if we do this, though there are no known bugs there. Still,
for future safety, its much better to only unlock cs_main if we've
made progress (not just tried a reorg which may make progress).

Github-Pull: bitcoin#2290
Rebased-From: 198f435

If multiple threads are invoking ActivateBestChain, it was possible to have
them working towards different tips, and we could arrive at a less work tip
than we should.  Fix this by introducing a ChainState lock which must
be held for the entire duration of ActivateBestChain to enforce
exclusion in ABC.

Github-Pull: bitcoin#2290
Rebased-From: a51a755

…s correct description of "prevblk-not-found"

Github-Pull: bitcoin#2290
Rebased-From: f68251d

After a recent bug discovered in callback ordering in MainSignals,
this test checks invariants in ordering of
BlockConnected / BlockDisconnected / UpdatedChainTip signals

Adaptation of btc@dd435ad40267f5c50ff17533c696f9302829a6a6

Github-Pull: bitcoin#2290
Rebased-From: 50dbec5

Github-Pull: bitcoin#2283
Rebased-From: dc2d22a

Github-Pull: bitcoin#2283
Rebased-From: a700fdf

It was only needed for the activation period, now that it's fully enforced, can be removed.
The activation time isn't needed, v5 enforcement checkpoint is ensuring that the chain cannot reorg to a time in which P2PKH stakes weren't enabled.

Github-Pull: bitcoin#2295
Rebased-From: 5aa3600

Github-Pull: bitcoin#2295
Rebased-From: 47cae28

…ptBlock`

`CBlock` has a member `fChecked` that has the exact same purpose as the `fAlreadyCheckedBlock` flag.

Github-Pull: bitcoin#2295
Rebased-From: 362a598

…ain` flow.

Github-Pull: bitcoin#2295
Rebased-From: 6355774

Github-Pull: bitcoin#2295
Rebased-From: ce1781e

ProcessNewBlock is called by ProcessMessage (NetMsgType::BLOCK command) which is doing the exact same check: if the node does not have the previous block, request sync up to it.

Github-Pull: bitcoin#2295
Rebased-From: 959936f

Github-Pull: bitcoin#2295
Rebased-From: 21646d8

…e that is too low.

Github-Pull: bitcoin#2215
Rebased-From: 60bc468

…not the stored value.